So you've written code that others could benefit from. What do you do with it? You can:
If you plan to ignore the general usefulness of your code, you can stop here (it won't hurt my feelings). For the rest of you -- preparing software to sell takes significantly more effort than preparing software to distribute as Open Source. Some claims I've seen are that it takes as much time to prepare the software to sell as it did to write the software initially. As someone who spent 10 years in the retail software industry, that 2X looks in the right order of magnitude, at least.
Those of us on the software development side don't notice that 2X so much, as most of the preparation effort is not software development effort. Offhand, I'd say the major additional software development effort in preparing software for sale is when you provide some sort of SDK for your users, but the user SDK must be different than the developer's normal environment (a simple scripting extension mechanism for a system written in platform-specific C++, for example). (This presumes that you can perform enough up-front testing of the user interface.)
Preparing software for sale, if you want to sell a lot of copies, means preparing for marketing and sales of your product so:
Without all of these factors in place, the number of copies you sell over time will be limited. If you don't supply the source of your system, your customers have to rely on you that much more as they (or their computer-literate friends) cannot look at the source to know how the software is supposed to work.
The other factor that comes in to play here is that most of us who write software do not work at retail software companies (10X as many? Anyone have figures on this?) Much software that is written separately from a product is software that scratches a programmer's itch. I've seen retail software companies that don't want to spread their efforts by trying to productize internally-developed software that is outside of the company's field, as productizing takes effort away from the company's main products.
Mozilla's Firefox is an example of where taking code and shoving it out the door as Open Source does not immediately mean thousands of developers will be clamoring to work on your masterpiece. Preparing software for distribution as Open Source takes effort too, but less effort, as the main non-programming effort is to get the word out about your software (that is, marketing for Open Source). Perl's CPAN (Comprehensive Perl Archive Network) is good at this, as CPAN contains the tools needed to help polish your software (Test::More, Perl::Critic, Module::Build, et.al.) along with a website and RSS feed to help inform the world about your new code. With the Internet, everyone can be a publisher, so you can publish your own marketing materials worldwide without spending a fortune on brochures, CDs, etc.
As I have stated before, I don't care whether an application is Open Source or not, as long as it does what I need it to do and does not do what I don't want it to do. Open Source significantly lowers the barriers for my own use of software, as I can go in and tweak the software if it doesn't work the way I want it too (and I've done so). If you have some code that you want to sell Closed Source, have at it — if it is good enough at an acceptable price for what it does, I will buy it. But making your code Open Source is easier, and may bring you as much additional income (indirectly through professional recognition) as trying to productize your code.
